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1. Abstract 


This document describes a method for broadcasting IP data ina 
unidirectional manner using the vertical blanking interval of 
television signals. It includes a description for compressing IP 
headers on unidirectional networks, a framing protocol identical to 
SLIP, a forward error correction scheme, and the NABTS byte 
structures. 


2. Introduction 


This RFC proposes several protocols to be used in the transmission of 
IP datagrams using the Vertical Blanking Interval (VBI) of a 
television signal. The VBI is a non-viewable portion of the 
television signal that can be used to provide point-to-multipoint IP 
data services which will relieve congestion and traffic in the 
traditional Internet access networks. Wherever possible these 
protocols make use of existing RFC standards and non-standards. 


Traditionally, point-to-point connections (TCP/IP) have been used 


even for the transmission of broadcast type data. Distribution of 
the same content--news feeds, stock quotes, newsgroups, weather 
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reports, and the like--are typically sent repeatedly to individual 
clients rather than being broadcast to the large number of users who 
want to receive such data. 


Today, IP is quickly becoming the preferred method of distributing 
one-to-many data on intranets and the Internet. The coming 
availability of low cost PC hardware for receiving television signals 
accompanied by broadcast data streams makes a defined standard for 
the transmission of data over traditional broadcast networks 
imperative. A lack of standards in this area as well as the expense 
of hardware has prevented traditional broadcast networks from 
becoming effective deliverers of data to the home and office. 


This document describes the transmission of IP using the North 
American Basic Teletext Standard (NABTS), a recognized and industry- 
supported method of transporting data on the VBI. NABTS is 
traditionally used on 525-line television systems such as NTSC. 
Another byte structure, WST, is traditionally used on 625-line 
systems such as PAL and SECAM. These generalizations have 
exceptions, and countries should be treated on an individual basis. 
These existing television system standards will enable the television 
and Internet communities to provide inexpensive broadcast data 
services. A set of existing protocols will be layered above the 
specific FEC for NABTS including a serial stream framing protocol 
similar to SLIP (RFC 1055 [Romkey 1988]) and a compression technique 
for unidirectional UDP/IP headers. 


The protocols described in this document are intended for the 
unidirectional delivery of IP datagrams using the VBI. That is, no 
return channel is described, or for that matter possible, in the VBI. 


The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", “SHALL NOT", 
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 
document are to be interpreted as described in RFC 2119. 


3. Proposed protocol stack 


The following protocol stack demonstrates the layers used in the 
transmission of VBI data. Each layer has no knowledge of the data it 
encapsulates, and is therefore abstracted from the other layers. At 
the link layer, the NABTS protocol defines the modulation scheme used 
to transport data on the VBI. At the network layer, IP handles the 


movement of data to the appropriate clients. In the transport layer, 
UDP determines the flow of data to the appropriate processes and 
applications. 
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4+------------------- + 
| | 
Application 
4------------------- + 
| ined 
| UDP | ) 
| |) 
$------------------- +  (-- IP 
| |) 
| IP | ) 
| |) 
+------------------- + 
| SLIP-style | 
| encapsulation | 
| | 
4------------------- + 
| FEC | 
|------------------- | 
| NABTS | 
| | 
4+--------- 4+--------- + 
| | 
| NTSC/other | 
| | 
4------------------- + 
| 
cable, off-air, etc. 
4+-------- <----<----<-------- 


These protocols can be described in a bottom up component model using 
the example of NABTS carried over NTSC modulation as follows: 


Video signal --> NABTS --> FEC --> serial data stream --> Framing 
protocol --> compressed UDP/IP headers --> application data 


This diagram can be read as follows: television signals have NABTS 
packets, which contain a Forward Error Correction (FEC) protocol, 
modulated onto them. The data contained in these sequential, ordered 
packets form a serial data stream on which a framing protocol 
indicates the location of IP packets, with compressed headers, 
containing application data. 


The structure of these components and protocols are described in 
following subsections. 
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3.1. VBI 


The characteristics and definition of the VBI is dependent on the 
television system in use, be it NTSC, PAL, SECAM or some other. For 
more information on Television standards worldwide, see ref [12]. 


3.1.1. 525 line systems 


A 525-line television frame is comprised of two fields of 262.5 
horizontal scan lines each. The first 21 lines of each field are not 
part of the visible picture and are collectively called the Vertical 
Blanking Interval (VBI). 


Of these 21 lines, the first 9 are used while repositioning the 
cathode ray to the top of the screen, but the remaining lines are 
available for data transport. 


There are 12 possible VBI lines being broadcast 60 times a second 
(each field 30 times a second). In some countries Line 21 is 
reserved for the transport of closed captioning data (Ref.[11]). In 
that case, there are 11 possible VBI lines, some or all of which 
could be used for IP transport. It should be noted that some of 
these lines are sometimes used for existing, proprietary, data and 
testing services. IP delivery therefore becomes one more data service 
using a subset or all of these lines. 


3.1.2. 625 Line Systems 


A 625-line television frame is comprised of two fields of 312.5 
horizontal scan lines each. The first few lines of each field are 
used while repositioning the cathode ray to the top of the screen. 
The lines available for data insertion are 6-22 in the first field 
and 319-335 in the second field. 


There are, therefore, 17 possible VBI lines being broadcast 50 times 
a second (each field 25 times a second), some or all of which could 
be used for IP transport. It should be noted that some of these 
lines are sometimes used for existing, proprietary, data and testing 
services. IP, therefore, becomes one more data service using a subset 
or all of these lines. 


3.2. NABTS 
The North American Basic Teletext Standard is defined in the 


Electronic Industry Association’s EIA-516, Ref. [2], and ITU.R 
BT.653-2, system C, Ref. [13]. It provides an industry-accepted 
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method of modulating data onto the VBI, usually of an NTSC signal. 
This section describes the NABTS packet format as it is used for the 
transport of IP. 


It should be noted that only a subset of the NABTS standard is used, 


as is common practice in NABTS implementations. Further information 
concerning the NABTS standard and its implementation can be found in 
EIA-516. 


The NABTS packet is a 36-byte structure encoded onto one horizontal 
scan line of a television signal having the following structure: 


0 1 2 3 
Od, 23) Al. Or hy Be QF! ABB 4s 9 ESTE A920) ok, 23? Alc TB. g Oe aL 
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 


| clock sync | byte sync | packet addr. | 
+-+-+-+-+-+-+-+-+-+-+-+-+-+-++H+HHHH HMHHMHHMHHMHH 
| packet address (cont.) | cont. index |PcktStructFlags | 


+-+-+-+-+-+-+-+-+ +H 
| user data (26 bytes) | 


: +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+- 
| | FEC 
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 


The two-byte Clock Synchronization and one-byte Byte Synchronization 
are located at the beginning of every scan line containing a NABTS 
packet and are used to synchronize the decoding sampling rate and 
byte timing. 


The three-byte Packet Address field is Hamming encoded (as specified 
in EIA-516), provides 4 data bits per byte, and thus provides 4096 
possible packet addresses. These addresses are used to distinguish 
related services originating from the same source. This is necessary 
for the receiver to determine which packets are related, and part of 
the same service. NABTS packet addresses therefore distinguish 
different data services, possibly inserted at different points of the 
transmission system, and most likely totally unrelated. Section 4 of 
this document discusses Packet Addresses in detail. 


The one-byte Continuity Index field is a Hamming encoded byte, which 
is incremented by one for each subsequent packet of a given Packet 
Address. The value or number of the Continuity Index sequences from 
0 to 15. It increments by one each time a data packet is transmitted. 
This allows the decoder to determine if packets were lost during 
transmission. 
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The Packet Structure field is also a Hamming encoded byte, which 
contains information about the structure of the remaining portions of 
the packet. The least significant bit is always "0" in this 
implementation. The second least significant bit specifies if the 
Data Block is full--"0" indicates the data block is full of useful 
data, and "1" indicates some or all of the data is filler data. The 
two most significant bits are used to indicate the length of the 
suffix of the Data Block--in this implementation, either 2 or 28 
bytes (10 for 2-byte FEC suffix, 11 for 28-byte FEC suffix). This 
suffix is used for the forward error correction described in the next 
section. The following table shows the possible values of the Packet 
Structure field: 


Data Packet, no filler DO 
Data Packet, with filler 8C 
FEC Packet Al 


The Data Block field is 26 bytes, zero to 26 of which is useful data 
(part of a IP packet or SLIP frame), the remainder is filler data. 
Data is byte-ordered least significant bit first. Filler data is 
indicated by an 0x15 followed by as many OxEA as are needed to fill 
the Data Block field. Sequential data blocks minus the filler data 
form an asynchronous serial stream of data. 


These NABTS packets are modulated onto the television signal 
sequentially and on any combination of lines. 


3.3. FEC 


Due to the unidirectional nature of VBI data transport, Forward Error 
Correction (FEC) is needed to ensure the integrity of data at the 
receiver. The type of FEC described here and in the appendix of this 
document for NABTS has been in use for a number of years, and has 
proven popular with the broadcast industry. It is capable of 
correcting single-byte errors and single- and double-byte erasures in 
the data block and suffix of a NABTS packet. In a system using 
NABTS, the FEC algorithm splits a serial stream of data into 364-byte 
"bundles". The data is arranged as 14 packets of 26 bytes each. A 
function is applied to the 26 bytes of each packet to determine the 
two suffix bytes, which (with the addition of a header) complete the 
NABTS packet (8+26+2). 


For every 14 packets in the bundle, two additional packets are 
appended which contain only FEC data, each of which contain 28 bytes 
of FEC data. The first packet in the bundle has a Continuity Index 
value of 0, and the two FEC only packets at the end have Continuity 
Index values of 14 and 15 respectively. This data is obtained by 
first writing the packets into a table of 16 rows and 28 columns. 
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The same expression as above can be used on the columns of the table 
with the suffix now represented by the bytes at the base of the 
columns in rows 15 and 16. With NABTS headers on each of these rows, 
we now have a bundle of 16 NABTS packets ready for sequential 
modulation onto lines of the television signal. 


At the receiver, these formulae can be used to verify the validity of 
the data with very high accuracy. If single bit errors, double bit 
errors, single-byte errors or single- and double-byte erasures are 
found in any row or column (including an entire packet lost) they can 
be corrected using the algorithms found in the appendix. The success 
at correcting errors will depend on the particular implementation 
used on the receiver. 


3.4. Framing 


A framing protocol identical to SLIP is proposed for encapsulating 
the packets described in the following section, thus abstracting this 
data from the lower protocol layers. This protocol uses two special 
characters: END (0xc0) and ESC (Oxdb). To send a packet, the host 
will send the packet followed by the END character. If a data byte 
in the packet is the same code as END character, a two-byte sequence 
of ESC (Oxdb) and Oxdc is sent instead. If a data byte is the same 
code as ESC character, a two-byte sequence of ESC (0Oxdb) and Oxdd is 
sent instead. SLIP implementations are widely available; see RFC 
1055 [Romkey 1988] for more detail. 


t-------------- 4+-—4+------------ r N a +--+ 
| packet |co] packet |db|dd| |co]| 
E a S 4+--4+------------ +--—+--+--------- +--+ 

END ESC END 


The packet framed in this manner shall be formatted according to its 
schema type identified by the schema field, which shall start every 


packet: 
+----------- 5 aR aaa ma I WI Sad SSE GR a eas ET a + 
| schema | packet (formatted according to schema) | 
| 1 byte | ?? bytes (schema dependant length) 
+----------- Fa a T a a a a + 
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In the case where the most significant bit in this field is set to 
"1", the length of the field extends to two bytes, allowing for 32768 
additional schemas: 


4+----------- 4+------------------------------ = === === + 

| extended | packet (formatted according to schema) | 
schema | ?? bytes (schema dependant length) 

| 2 bytes | | 

+----------- 4+------------------------------ = ---- === === + 


In the section 3.5, one such schema for sending IP is described. 
This is the only schema specified by this document. Additional 
schemas may be proposed for other packet types or other compression 
schemes as described in section 7. 


3.4.1 Maximum Transmission Unit Size 


The maximum length of an uncompressed IP packet, or Maximum- 
Transmission Unit (MTU) size is 1500 octets. Packets larger than 
1500 octets MUST be fragmented before transmission, and the client 
VBI interface MUST be able to receive full 1500 octet packet 
transmissions. 


3.5. IP Header Compression Scheme 


The one-byte scheme defines the format for encoding the IP packet 
itself. Due to the value of bandwidth, it may be desirable to 
introduce as much efficiency as possible in this encoding. One such 
efficiency is the optional compression of the UDP/IP header using a 
method related to the TCP/IP header compression as described by Van 
Jacobson (RFC 1144). UDP/IP header compression is not identical due 
to the limitation of unidirectional transmission. One such scheme is 
proposed in this document for the compression of UDP/IP version 4. 

It is assigned a value of 0x00. All future encapsulation schemes 
should use a unique value in this field. 


Only schema 0x00 is defined in this document; this schema must be 
supported by all receivers. In schema 0x00, the format of the IP 
packet itself takes one of two forms. Packets can be sent with full, 
uncompressed headers as follows: 
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0 1 2 3 
iE a 6? FE 8-908 Ti 2 Ba 3678) 90 A234 3 6 8 9 On 
Patt Ht t rt atta tata t arta t arta t arta t tata tata tata tata tata tatatata tat 

| 0 | group | uncompressed IP header (20 bytes) 
tot—t-4t-4-4+-4-4-4 + 


+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+- 
| uncompressed UDP header (8 bytes) 


+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+- 
| payload (<1472 bytes) 
+-+-+-+-+-+-+-+-+ 


+-+-+-+-+-+-+-+-+-+-+++ +++ HHHH 
| CRC | 
+-+-+-+-+-+-+-+-+-+-+++ titi titi pi pepe p HHHH 


The first byte in the 0x00 scheme is the Compression Key. It isa 
one-byte value: the first bit indicates if the header has been 
compressed, and the remaining seven bits indicate the compression 
group to which it belongs. 


If the high bit of the Compression Key is set to zero, no compression 
is performed and the full header is sent, as shown above. The client 
VBI interface should store the most recent uncompressed header for a 
given group value for future potential use in rebuilding subsequent 
compressed headers. Packets with identical group bits are assumed to 
have identical UDP/IP headers for all UDP and IP fields, with the 
exception of the "IP identification" and "UDP checksum" fields. 


Group values may be recycled following 60 seconds of nonuse by the 
preceding UDP/IP session (no uncompressed packets sent), or by 
sending packets with uncompressed headers for the 60-second duration 
following the last packet in the preceding UDP/IP session. 
Furthermore, the first packet sent following 60 seconds of nonuse, or 
compressed header packets only use, must use an uncompressed header. 
Client VBI interfaces should disregard compressed packets received 60 
or more seconds after the last uncompressed packet using a given 
group address. This avoids any incorrectly decompressed packets due 
to group number reuse, and limits the outage due to a lost 
uncompressed packet to 60 seconds. 


If the high bit of the Compression Key is set to one, a compressed 


version of the UDP/IP header is sent. The client VBI interface must 
then combine the compressed header with the stored uncompressed 
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header of the same group and recreate a full packet. For compressed 
packets, the only portions of the UDP/IP header sent are the "IP 
identification" and "UDP checksum" fields: 


0 1 2 3 
OL, 2: 3) 496) TF 8 O90) Ae 2 SAS GF 879 OL. 234 306. T7 8 Oe OL 
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 


|1| group | IP identification | UDP checksum| 
foHoFofH fof tipi pi tigi tipi pig p i pip git ipa pig gigi gg p gig gt 
|UDP cksm (cont) | payload (<1472 bytes) 


+-+-+-+-+-+-+-+-+ + 


+-+-+-+-+-+-+-+-+-+-+++ +++ HHHH 
| CRC | 
+-+-+-+-+-+-+-+-+-+-+++ titi t iti pipe pgp HHHH 


All datagrams belonging to a multi fragment IP packet shall be sent 
with full headers, in the uncompressed header format. Therefore, 
only packets that have not been fragmented can be sent with the most 
significant bit of the compression key set to "1". 


A 32-bit CRC has also been added to the end of every packet in this 
scheme to ensure data integrity. It is performed over the entire 
packet including schema byte, compression key, and either compressed 
or uncompressed headers. It uses the same algorithm as the MPEG-2 
transport stream (ISO/IEC 13818-1). The generator polynomial is: 


1+ D + D2 + D4 + D5 + D7 + D8 + D10 + D11 + D12 + D16 + D22 + D23 + 
D26 + D32 


As in the ISO/IEC 13818-1 specification, the initial state of the sum 
is OxFFFFFFFF. This is not the same algorithm used by Ethernet. This 
CRC provides a final check for damaged datagrams that span FEC 
bundles or were not properly corrected by FEC. 


4. Addressing Considerations 


The addressing of IP packets should adhere to existing standards in 
this area. The inclusion of an appropriate source address is needed 
to ensure the receiving client can distinguish between sources and 
thus services if multiple hosts are sharing an insertion point and 
NABTS packet address. 


NABTS packet addressing is not regulated or standardized and requires 
care to ensure that unrelated services on the same channel are not 
broadcasting with the same packet address. This could occur due to 
multiple possible NABTS insertion sites, including show production, 
network redistribution, regional operator, and local operator. 
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Traditionally, the marketplace has recognized this concern and made 
amicable arrangements for the distribution of these addresses for 
each channel. 


5. IANA Considerations 


IANA will register new schemas on a "First Come First Served" basis 
[RFC 2434]. Anyone can register a scheme, so long as they provide a 
point of contact and a brief description. The scheme number will be 
assigned by IANA. Registrants are encouraged to publish complete 
specifications for new schemas (preferably as standards-track RFCs), 
but this is not required. 


6. Security Considerations 


As with any broadcast network, there are security issues due to the 
accessibility of data. It is assumed that the responsibility for 
securing data lies in other protocol layers, including the IP 
Security (IPSEC) protocol suite, Transport Layer Security (TLS) 
protocols, as well as application layer protocols appropriate for a 
broadcast-only network. 


7. Conclusions 


This document provides a method for broadcasting Internet data over a 
television signal for reception by client devices. With an 
appropriate broadcast content model, this will become an attractive 
method of providing data services to end users. By using existing 
standards and a layered protocol approach, this document has also 
provided a model for data transmission on unidirectional and 
broadcast networks. 
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12. Appendix A: Forward Error Correction Specification 


This FEC is optimized for data carried in the VBI of a television 
signal. Teletext has been in use for many years and data 
transmission errors have been categorized into three main types: 1) 
Randomly distributed single bit errors 2) Loss of lines of NABTS data 
3) Burst Errors 


The quantity and distribution of these errors is highly variable and 
dependent on many factors. The FEC is designed to fix all these 
types of errors. 


12.1. Mathematics used in the FEC 


Galois fields form the basis for the FEC algorithm presented here. 
Rather then explain these fields in general, a specific explanation 
is given of the Galois field used in the FEC algorithm. 


The Galois field used is GF(2%8) with a primitive element alpha of 
00011101. This is a set of 256 elements, along with the operations 
of "addition", "subtraction", "division", and "multiplication" on 
these elements. An 8-bit binary number represents each element. 


The operations of "addition" and "subtraction" are the same for this 
Galois field. Both operations are the XOR of two elements. Thus, 
the "sum" of 00011011 and 00000111 is 00011100. 


Division of two elements is done using long division with subtraction 
operations replaced by XOR. For multiplication, standard long 
multiplication is used but with the final addition stage replaced 
with XOR. 


All arithmetic in the following FEC is done modulo 100011101; for 
instance, after you multiply two numbers, you replace the result with 


its remainder when divided by 100011101. There are 256 values in 
this field (256 possible remainders), the 8-bit numbers. It is very 
important to remember that when we write A*B = C, we more accurately 
imply modulo(A*B) = C. 


It is obvious from the above description that multiplication and 
division is time consuming to perform. Elements of the Galois Field 
share two important properties with real numbers. 


A*B = POWERalpha(LOGalpha(A) + LOGalpha (B) ) 
A/B = POWERalpha(LOGalpha(A) - LOGalpha (B) ) 
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The Galois Field is limited to 256 entries so the power and log 
tables are limited to 256 entries. The addition and subtraction 
shown is standard so the result must be modulo alpha. Written as a 
"C" expression: 


A*B 
A/B 


apower[alog[A] + alog[B]] 
apower[255 + alog[A] - alog[B]] 


You may note that alog[A] + alog[B] can be greater than 255 and 
therefore a modulo operation should be performed. This is not 
necessary if the power table is extended to 512 entries by repeating 
the table. The same logic is true for division as shown. The power 
and log tables are calculated once using the long multiplication 
shown above. 


12.2. Calculating FEC bytes 


The FEC algorithm splits a serial stream of data into "bundles". 
These are arranged as 16 packets of 28 bytes when the correction 
bytes are included. The bundle therefore has 16 horizontal codewords 
interleaved with 28 vertical codewords. Two sums are calculated for 
a codeword, SO and S1. SO is the sum of all bytes of the codeword 
each multiplied by alpha to the power of its index in the codeword. 
S1 is the sum of all bytes of the codeword each multiplied by alpha 
to the power of three times its index in the codeword. In "C" the 
sum calculations would look like: 


if (codeword[i] != 0) 


Sumo 
Sum1 


} 


sum0 ^ power[i + alog[codeword[i]]]; 
suml ^ power[3*i + alog[codeword[i]]]; 


Note that the codeword order is different from the packet order. 
Codeword positions 0 and 1 are the suffix bytes at the end of a 
packet horizontally or at the end of a column vertically. 


When calculating the two FEC bytes, the summation above must produce 
two sums of zero. All codewords except 0 and 1 are know so the sums 
for the known codewords can be calculated. Let’s call these values 
tot0 and totl. 


Panabaker, et al. Standards Track [Page 15] 


RFC 2728 IPVBI November 1999 


12. 


Sum0 = tot0*power[0+alog[codeword[0]]]*power[1l+alog[codeword[1]]] 
Sum1 totl^power[0+alog[codeword[0]]]^power[3+alog[codeword[1]]] 


This gives us two equations with the two unknowns that we can solve: 


codeword[1] 
codeword[0] 


power [255t+alog[tot0*tot1]-alog[power[1]“*power[3]]] 
tot0*power [alog[codeword[1]]+alog[power[1]]] 


3. Correcting Errors 


This section describes the procedure for detecting and correcting 
errors using the FEC data calculated above. Upon reception, we begin 
by rebuilding the bundle. This is perhaps the most important part of 
the procedure because if the bundle is not built correctly it cannot 
possibly correct any errors. The continuity index is used to 
determine the order of the packets and if any packets are missing 
(not captured by the hardware). The recommendation, when building 
the bundle, is to convert the bundle from packet order to codeword 
order. This conversion will simplify the codeword calculations. This 
is done by taking the last byte of a packet and making it the second 
byte of the codeword and taking the second last byte of a packet and 
making it the first byte of a codeword. Also the packet with 
continuity index 15 becomes codeword position one and the packet with 
continuity index 14 becomes codeword position zero. The same FEC is 
used regardless of the number of bytes in the codeword. So let’s 
think of the codewords as an array codeword[vert] [hor] where vert is 
16 packets and hor is 28. Each byte in the array is protected by 
both a horizontal and a vertical codeword. For each of the 
codewords, the sums must be calculated. If both the sums for a 
codeword are zero then no errors have been detected for that 
codeword. Otherwise, an error has been detected and further steps 
need to be taken to see if the error can be corrected. In "C" the 
horizontal summation would look like: 
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for (i = 0; i < 16; i++) 
{ 
sum0 = 0; 
suml = 0; 
for (j = 0;j < hor; j++) 
{ 
if (codeword[i][j] != 0) 
{ 
sum0 = sum0 ^ power[j + alog[codeword[i][j]]; 
suml = suml ^ power[3*j + alog[codeword[i][j]]; 
} 
} 
if ((sum0 != 0) || (suml != 0)) 


} 


{ 
Try Correcting Packet 


} 


Similarly, vertical looks like: 


for 


{ 


} 


12.4. 


(j = O;i < hor;itt) 
sumo 0; 
suml = 0; 
for (i = O;i < 16;1i++) 
{ 
if (codeword[i][j] != 0) 
{ 
sum0 = sum0 ^ power[i + alog[codeword[i][j]]; 
suml = suml ^ power[3*i + alog[codeword[i][j1]]; 
} 
} 
if ((sum0 != 0) || (suml != 0)) 
{ 
Try Correcting Column 
} 
Correction Schemes 


This FEC provides four possible corrections: 


1) 


2) 
3) 
4) 


Single bit correction in codeword. All single bit errors. 
Double bit correction in a codeword. Most two-bit errors. 


1999 


Single byte correction in a codeword. All single-byte errors. 
Packet replacement. One or two missing packets from a bundle. 
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{2 


LAE 


4.1. Single Bit Correction 


When correcting a single-bit in a codeword, the byte and bit position 
must be calculated. The equations are: 


Byte = 1/2LOGalpha(S1/S0) 
Bit = 8LOGalpha(S0O/POWERalpha (Byte) ) 


In "C" this is written: 


Byte = alog[power[255 + alog[suml] - alog[sum0]]]; 
if (Byte & 1) 

Byte = Byte + 255; 
Byte = Byte >> 1; 
Bit = alog[power[255 + alog[sum0] - Byte]] << 3; 
while (Bit > 255) 

Bit = Bit - 255; 


The error is correctable if Byte is less than the number of bytes in 
the codeword and Bit is less than eight. For this math to be valid 
both sumO and suml must be non-zero. The codeword is corrected by: 


codeword[Byte] = codeword[Byte] ^ (1 << Bit); 


4.2. Double Bit Correction 


Double bit correction is much more complex than single bit correction 
for two reasons. First, not all double bit errors are deterministic. 
That is two different bit patterns can generate the same sums. 
Second, the solution is iterative. To find two bit errors you assume 
one bit in error and then solve for the second error as a single bit 
error. 


The procedure is to iteratively move through the bits of the codeword 
changing each bit’s state. The new sums are calculated for the 
modified codeword. Then the single bit calculation above determines 
if this is the correct solution. If not, the bit is restored and the 
next bit is tried. 


For a long codeword, this can involve many calculations. However, 
tricks can speed the process. For example, the vertical sums give a 
strong indication of which bytes are in error horizontally. Bits in 
other bytes need not be tried. 
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12:5 


12:3 


4.3. Single Byte Correction 


For single byte correction, the byte position and bits to correct 
must be calculated. The equations are: 


Byte 
Mask 


1/2*LOGalpha(S1/S0) 
SO0/POWERalpha [Byte] 


Notice that the byte position is the same calculation as for single 
bit correction. The mask will allow more than one bit in the byte to 
be corrected. In "C" the mask calculation looks like: 


Mask = power[255 + alog[sum0] - Byte] 


Both sum0O and suml must be non-zero for the calculations to be valid. 
The Byte value must be less than the codeword length but Mask can be 
any value. This corrects the byte in the codeword by: 


Codeword[Byte] = Codeword[Byte] ^ Mask 
4.4. Packet Replacement 


If a packet is missing, as determined by the continuity index, then 
its byte position is known and does not need to be calculated. The 
formula for single packet replacement is therefore the same as for 
the Mask calculation of single byte correction. Instead of XORing an 
existing byte with the Mask, the Mask replaces the missing codeword 
position: 


Codeword[Byte] = Mask 


When two packets are missing, both the codeword positions are known 
by the continuity index. This again gives two equations with two 
unknowns, which is solved to give the following equations. Mask2 = 
POWERalpha (2*Bytel1) *S0+S1 


POWERalpha (2*Bytel+Byte2) +POWERalpha (3*BYTEZ2) 
Mask1 = SO + Mask2*POWERalpha (Byte2) /POWERalpha (BYTE1) 
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In "C" these equations are written: 


if (sum0 == 0) 
{ 
if (suml == 0) 
mask2 = 0; 
else 
mask2=power [255+alog[sum1]-alog[power [byte2+2*bytel1] 
“power [3*Byte2]]]; 
} 
else 
{ 
if ((a=suml*power[alog[sum0]+2*bytel]) == 0) 
mask2 = 0; 
else 
mask2 = 
power [255+alog[a]-alog[power [byte2+2*bytel] “power [3*byte2]]]; 
} 


if (mask2 = 0) 
{ 
if (sum0 == 0) 
maskl = 0; 
else 
maskl = power[255+alog[sum0]-bytel]; 
} 
else 
{ 
if ((a=sum0“power[alog[mask2] + byte2]) == 0) 
maskl = 0; 
else 
maskl = power[255+alog[a]-bytel]; 


Notice that, in the code above, care is taken to check for zero 


values. The missing codeword position can be fixed by: 
codeword[bytel] = maskl; 
codeword[byte2] = mask2; 


12.5. FEC Performance Considerations 


1999 


The section above shows how to correct the different types of errors. 
It does not suggest how these corrections may be used in an algorithm 
to correct a bundle. There are many possible algorithms and the one 


chosen depends on many variables. These include: 
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The amount of processing power available 
The number of packets per VBI to process 
The type of hardware capturing the data 
The delivery path of the VBI 
How the code is implemented 


As a minimum, it is recommended that the algorithm use single bit or 
single byte correction for one pass in each direction followed by 
packet replacement if appropriate. It is possible to do more than 
one pass of error correction in each direction. The theory is that 
errors not corrected in the first pass may be corrected in the second 
pass because error correction in the other direction has removed some 
errors. 


In making choices, it is important to remember that the code has 
several possible states: 


1) Shows codeword as correct and it is. 

2) Shows codeword as correct and it is not (detection failure). 

3) Shows codeword as incorrect but cannot correct (detection). 

4) Shows codeword as incorrect and corrects it correctly 
(correction). 

5) Shows codeword as incorrect but corrects wrong bits (false 
correction). 

There is actually overlap among the different types of errors. For 

example, a pair of sums may indicate both a double bit error anda 

byte error. It is not possible to know at the code level which is 

correct and which is a false correction. In fact, neither might be 


correct if both are false corrections. 


If you know something about the types of errors in the delivery 
channel, you can greatly improve efficiency. If you know that errors 
are randomly distributed (as in a weak terrestrial broadcast) then 
single and double bit correction are more powerful than single byte. 
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14. 


Appendix B: Architecture 


The architecture that this document is addressing can be broken down 
into three areas: insertion, distribution network, and receiving 
client. 


The insertion of IP data onto the television signal can occur at any 
part of the delivery system. A VBI encoder typically accepts a video 
signal and an asynchronous serial stream of bytes forming framed IP 
packets as inputs and subsequently packetizes the data onto a 
selected set of lines using NABTS and an FEC. This composite signal 
is then modulated with other channels before being broadcast onto the 
distribution network. Operators further down the distribution chain 
could then add their own data, to other unused lines, as well. The 
distribution networks include coax plant, off-air, and analog 
satellite systems and are primarily unidirectional broadcast 
networks. They must provide a signal to noise ratio, which is 
sufficient for FEC to recover any lost data for the broadcast of data 
to be effective. 


The receiving client must be capable of tuning, NABTS waveform 
sampling as appropriate, filtering on NABTS addresses as appropriate, 
forward error correction, unframing, verification of the CRC and 
decompressing the UDP/IP header if they are compressed. All of the 
above functions can be carried out in PC software and inexpensive 
off-the-shelf hardware. 


Appendix C: Scope of proposed protocols 


The protocols described in this document are for transmitting IP 
packets. However, their scope may be extensible to other 
applications outside this area. Many of the protocols in this 
document could be implemented on any unidirectional network. 


The unidirectional framing protocol provides encapsulation of IP 
datagrams on the serial stream, and the compression of the UDP/IP 
headers reduces the overhead on transmission, thus conserving 
bandwidth. These two protocols could be widely used on different 
unidirectional broadcast networks or modulation schemes to 
efficiently transport any type of packet data. In particular, new 
versions of Internet protocols can be supported to provide a 
standardized method of data transport. 
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15. Full Copyright Statement 
Copyright (C) The Internet Society (1999). All Rights Reserved. 


This document and translations of it may be copied and furnished to 
others, and derivative works that comment on or otherwise explain it 
or assist in its implementation may be prepared, copied, published 
and distributed, in whole or in part, without restriction of any 
kind, provided that the above copyright notice and this paragraph are 
included on all such copies and derivative works. However, this 
document itself may not be modified in any way, such as by removing 
the copyright notice or references to the Internet Society or other 
Internet organizations, except as needed for the purpose of 
developing Internet standards in which case the procedures for 
copyrights defined in the Internet Standards process must be 
followed, or as required to translate it into languages other than 
English. 


The limited permissions granted above are perpetual and will not be 
revoked by the Internet Society or its successors or assigns. 


This document and the information contained herein is provided on an 
"AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING 
TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING 
BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION 
HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF 
MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 
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